1. Field of the Invention
The present invention relates, in general, to a system and method for generating programs associated with Internet web pages that can persist from one web page to another without requiring repeated downloading of the programs from a remote server, or the like.
2. Description of the Prior Art
The World Wide Web is generally considered to be largely stateless because one web page cannot transfer information to a page that is outside of its scope, or the scope of its parent. For example, programs or subroutines, such as JAVA applets, that are embedded in the Hyper Text Markup Language (HTML) code for a web page, can only be run in association with that page, and cannot be stored on a user""s computer for subsequent use with other web pages. This restriction is currently bypassed, to some extent, in several ways. One way is to use active server pages (ASPs) on the host server that can generate pages dynamically, on the basis of information that persists on the server. For instance, MICROSOFT""s INTERNET INFORMATION SERVER can be used to generate active server pages that act as if they have memory. There is no intelligence, however, provided in the browser itself.
As an illustration, consider a xe2x80x9cshopping cartxe2x80x9d example where items are offered for sale at a store site on the Internet, and a list of items selected by a purchaser (client) is generated as they enter their order. A central computer has a database of the items for sale, and pictures, descriptions and prices for each item. The items are assembled into web pages that are encoded using HTML, as is conventional. In addition, the web pages that display the items are each ASPs, because instructions are contained in these pages that will generate the final HTML page that will be sent to a client who wishes to place an order for one or more of the items. The central computer does processing, according to instructions contained on the ASP, retrieves all of the required elements from databases, and assembles a page that the client computer""s browser can read. Thus, the items are stored in the central computer, and central computer processing generates the page. As a result, the pages are usually in the form of grid-like, computer-generated lists.
Suppose the client buys something on a page, by pressing a xe2x80x9cbuttonxe2x80x9d on the web page. The button sends information to the central computer, which stores that information centrally and then generates another page, indicating what has been purchased. This new page is then downloaded to the client""s computer, which displays the new page with its browser. Links are kept open at the central computer that wait for the client to enter additional purchase requests. If another purchase request is received, the central computer generates yet another page that contains the updated purchase information, and once again, downloads this page to the client""s computer. Once the client finalizes their order, the central computer collects credit, address and other information from the client to conclude the transaction. Clearly, the foregoing procedure is demanding on the central computer""s resources since it requires that the central computer generate and download an updated page each time another item is selected.
Memory can also be maintained on the browser, through what are known as xe2x80x9ccookiesxe2x80x9d that may be used to store name-value pairs on a client""s computer. A cookie is a string of up to 2K of name=value pairs, separated by ampersands, such as Product1=jamandProduct2=butter andPrice1=14andPrice2=22.95. These cookies are used by JAVASCRIPT, which is a scripting language contained in HTML. In this technique, a program that is executed on one page tests for the presence of the name-value pairs in memory associated with a browser, and when it finds them, it assumes that they were placed there by some other program on a previous page, and it operates on the information. Each page contains, in its entirety, the code that runs on that page. It must also contain the code to store and to retrieve cookies. This is sometimes done on cheaper shopping carts, usually for very small merchants.
In the shopping cart example, cookies work in the following manner. A merchant""s items for sale are located on a normal HTML page. The central computer does no processing, but simply delivers the page. On that page, there can be up to 200 to 300 lines of JAVASCRIPT code. It is meticulously written to display the items for sale, and to store cookies. A purchaser buys something by pressing a button. The code on that page looks to see if there is a cookie that indicates that the purchaser has bought something else previously. If so, the program retrieves the cookie, and displays the total sales, including previously selected items, as well as the currently selected item Then, this information is stored in a revised cookie. Now suppose that the purchaser jumps to the next HTML shopping page. That page has to contain all of the JAVASCRIPT code all over again, because there is no memory of the code from one HTML page to another. As with the previous page, the program then looks to see if there is a cookie, and if there is, it retrieves it and displays the sales from previous pages. Thus, although the use of cookies eliminates the need for the central computer to perform processing of the purchase information through storage of name=value pairs in the browser computer""s memory, it is still necessary for each page to contain extensive JAVASCRIPT code, and this tends to place major restrictions on web page design freedom.
Recent browsers, MICROSOFT EXPLORER 4 and 5 in particular, implement Dynamic HTML, which allows the persistence of some variables on the browser. However, neither this limited persistence nor any of the other aforementioned techniques have yet reached the stage at which a particular program can survive from page to page on the browser, without any intervention from the server gathering, remembering and processing information. As a result, anytime the same program is to be utilized with each of a plurality of sequentially downloaded or accessed web pages, the program and any associated data must either be downloaded from the server to the client with each page, or it must remain resident on a server, and interact with each page, thus not only taxing the server""s resources, but also substantially slowing the client computer""s processing speed.
The present invention overcomes the drawbacks of the aforementioned techniques through provision of methods by which programs and data associated with web pages are automatically stored in a computer""s or other computing device""s memory for subsequent use in association with other web pages. This is achieved through use of the inherent characteristics of a software engine, such as JAVA""s VIRTUAL MACHINE (JVM), that runs on the computing device, and executes applets and other programs that are embedded in the HTML coding of web pages when they are loaded on the computer. More particularly, the present invention employs first and second techniques by which a program generated object, such as a shopping cart, can be generated by loading of a first web page containing the necessary code for generating the object, and will remain, or appear to remain, generated as additional web pages are loaded on the computer.
In the first technique, program code is added to the HTML of each of a plurality of web pages that is loaded and executed by the software engine to generate the object when a first of the web pages is loaded on the computer. As is conventional in JAVA programming, the program code includes a tag that identifies the program by name and codebase so that if the software engine has already executed the same program during a previous page load, the codebase for the program, which is now resident in the computer""s memory but in a suspended or inactive state, will be accessed to reactivate the same program, thereby re-generating the object without reloading the program from the HTML code of the web page.
The key to the first technique is that a number of variables are defined in the program as static variables that can be modified during execution of the program. Static variables in JAVA have the characteristic that they will be remembered by the software engine even if the program is suspended or rendered inactive by loading of another web page. Thus, in a shopping cart example, if the identities, quantities and prices of selected items are defined in the shopping cart program as static variables, whose values can be changed through selection of items from an associated web page, then the values of these variables will remain stored by the JVM in memory along with the rest of the program code when another web page is loaded. If this new web page then also includes a reference or call to the same applet or program, the JVM will reactivate the shopping cart program along with the values of the static variables as they were left in the last page. The result is that through this repeated reactivation of the program and static variables stored in memory by the JVM, the shopping cart can be made to appear as if it continually persists as a purchaser surfs through a group of shopping site web pages. Further, there is no need for the purchaser""s or client""s computer or other device to communicate with the shopping site server until they are ready to submit their complete order for processing.
Thus, in the shopping cart example, as a purchaser or client selects items from a page, these items are added to the shopping cart, thus modifying the various static variables that define the elements of the cart, such as item ID, quantity and price. When the client now navigates to another web page containing information on additional items for sale, the shopping cart program is temporarily suspended along with the current values of the static variables. However, as soon as the next page is loaded, the JVM detects the applet identification information in the new page""s HTML code, and immediately reactivates the shopping cart program along with the static variables as they were last left. This process is repeated over and over as the client surfs from page to page. Once the client is finished with their purchases, the final shopping cart information can be sent along with the client""s other necessary identification information to the shopping site""s server, which processes the order. It should be noted that with this arrangement, the server is not involved in the processing of the shopping cart information until the purchaser has finalized their order. As a result, substantial server resources are saved.
The second technique is employed to extend the persistence of a program generated object, such as a shopping cart frame or other graphical user interface, even when web pages are loaded in the computer that do not contain any reference to the program which generates the object. In the first embodiment of the invention discussed previously, the program will not be reactivated if the next loaded web page does not contain a reference or call to the program. Thus, the shopping cart will not persist if a client navigates to a web page that is not associated with the shopping site. However, the shopping cart can be made to persist by modifying the program code in such a manner that the JVM or other software engine will execute the applet or program upon loading of an initial web page that contains the applet code, but will de-couple the program from the web page so that the JVM will continue executing the program even when the web page is closed. This is achieved by using an indirect reference in the applet to a separate class that contains all of the necessary code to run the shopping cart or other program. When the applet is executed by the JVM, the shopping cart program contained in the separate class is also executed, but now operates independently of the applet. This is because when a web page is closed or unloaded, any applets referenced in the web page will be suspended or deactivated by the JVM as discussed previously. However, since the separate class was purposely defined not to be in the applet itself, the JVM will continue to run the shopping cart program even after the page has been closed. As a result, the shopping cart will persist even when the client surfs to other web pages that are not related to the shopping site.
In both embodiments of the invention, a number of optional features are preferably employed. For example, execution of the applets or programs can also trigger downloading of a separate database that can be accessed during execution of the program. This arrangement is useful, for example, for downloading price updates that can be accessed by the shopping cart program In addition, each web page can be modified to load different operational parameters with the program so that the program will run differently with different pages, even though the exact same program code is being used.
The foregoing methods thereby eliminate the need for a remote or central server computer to store the program data, and to generate program-containing pages each time a new web page is requested. Unlike the prior art technique of using cookies, the effective memory inherently created by the JVM goes far beyond name=value pairs, and extensive JAVASCRIPT coding on each page is unnecessary. Also, unlike the prior technique of using ASPs, the server is not bogged down with computationally intensive processing, thus freeing up resources. As a result, the shopping cart program or other program can be hosted on a very simple central server, and yet it still has the design freedom of the most expensive machines and sites.